Exception strategies are used to handle exception conditions when an error occurs processing an event. There are two objects that support Exception strategies; components and connectors, plus a common component exception strategy for components can be set on the model.

Cannot resolve external resource into attachment.

Exception Strategies assoicated with components or the Model are used to handle component exceptions. These are typically business logic exceptions and the user will often want to customise the exception handler to control how these exceptions are logged and routed.

Exceptions strategies associated with the connector handle exceptions thrown when events are recieved or sent using a connector. It is less common that these strategies will be customised by the developer but they may be configured to route exceptions to a common error queue.

The default exception strategy used by the model (and thus all components managed by the Model) is org.mule.impl.DefaultComponentExceptionStrategy and the connectors use org.mule.impl.DefaultExceptionStrategy by default. Both of these strategies can be configured to dispatch to one or more endpoints.

Component Exception Strategies

A strategy can be set on a component using the <exception-strategy> element in Mule Xml -

<mule-descriptor name="myComponent"
    implementation="org.foo.MyComponent">
    ...
    <exception-strategy className="
        org.mule.impl.DefaultComponentExceptionStrategy"/>
</mule-descriptor>

Or you can set a common strategy for all components managed by the Model by setting it on the Model -

<model name="myModel">
    ...
    <exception-strategy className="
        org.mule.impl.DefaultComponentExceptionStrategy"/>
    ...
</model>

This will cause all components to use this exception strategy unless there is one explicitly defined for the component.

You can set a endpoint on an exception strategy to forward the event that failed to a destination such as an error queue. The org.mule.impl.DefaultComponentExceptionStrategy is a default implementation that can be configured with an endpoint i.e.

<mule-descriptor name="mycomponent"
    implementation="org.foo.mycomponent">
    ...
    <exception-strategy className="
            org.mule.impl.DefaultComponentExceptionStrategy">
        <endpoint address="jms://error.queue"/>
    </exception-strategy>
</mule-descriptor>

To implement your own strategy you class can extend the org.mule.impl.AbstractExceptionListener though it is recommended that you extend the DefaultComponentExceptionStrategy and just overload the defaultHandler() method. Bean properties can be set on your custom exception strategy in the same way as other Mule configured objects using a <properties> element.

<mule-descriptor name="myComponent"
    implementation="org.foo.MyComponent">
    ...
    <exception-strategy className="
        org.mule.impl.DefaultComponentExceptionStrategy">
        <endpoint address="jms://error.queue"/>
        <properties>
            <property name="foo" value="bar"/>
        </properties>
    </exception-strategy>
</mule-descriptor>

It is up to the defaultHandler() method to do all necessary processing to contain the exception. In other words an exception should never be thrown from an Exception Strategy. In situations were a fatal error occurs the strategy must manage this as well. For example, if an error queue is being used but the dispatch fails you might want to stop the current component and fire a server notification to alert a system monitor and write the event to file.

In some situations, you might want to change the say exceptions are logged. If so, all you have to do is override the logException() method from the AbstractExceptionListener. 

Connector Exception Strategies

connector Exception Strategies are configured in the same way and behave in the same way as Component exception Strategies.

<connector name="tcpConnector"
    classname="org.mule.providers.tcp.TcpConnector">
    ...
    <exception-strategy className="
        org.mule.impl.DefaultExceptionStrategy"/>
</connector>

The main difference is the type of exceptions that a Connector Exception Strategy will have to deal with. These exceptions will typically be connection related exceptions that may or may not be recoverable. The org.mule.impl.DefaultExceptionStrategy is the default used for connectors that simply logs the exception and continues.

We are currently working a more advanced Exception handling mechanism for connectors that will allow for custom retry policies and will manage the state of the connector so that it can be taken on/off line automatically based on the type of exception that occurs and admin events that can be used to trigger a change of state of the connector.